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Method and system for single sign-on user access to multiple web servers 



(57) Methods and systems for single sign-on user 
access to multiple web servers are provided. A user is 
authenticated at a first web server (e.g., by user name 
and password). The first web server provides a web 
page to the user having a service selector (e.g., a 
hyperlink comprising the URL of a second web server 
offering the service indicated by the selector). When the 
user activates the service selector, the first web server 
constructs and transmits an encrypted authentication 
token (e.g., a cookie) from the first web server to a sec- 
ond web server via the user client. The first and second 
web servers share a sub-domain. The authentication 
token comprises an expiration time and is digitally 
signed by the first web server and is authenticated at 
the second web server. Upon authentication, the sec- 
ond web server allows the user to conduct a session at 
the second web server. 
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5 ^53™^.^ 

.amber 24. ,999. which is hara* <L££^^££Z '° * FM - ta « "«> *»—.• M Sap- 

H. Field of the Invention 

servers. 9 Y 6th ° d and Sys,em ,or Priding single sign-on user access to multiple web 

is III. Background of the Invention 

In orter to aggregat. luncdoouli, » »e c^ome?« m. .^IT "f"™* °' 3l " eren ' "« b •«*-«»> mi 
such as a UNIX platform, an NT p.atform orsome J^Z. !J2 ?* l,Ca J? n servers ma V em P'°y different platforms. 

ir , _ „ llhout rep „„ log , ne cu r^rr^;„:^r :rr™=r^ 

"^"PPO* casing a^,™,,™,^^^ 

.an. tar aing.a algn-oa as., accass ,„ ™„ip te ,Z 1 .TI^LT' k""" 6 " * " ™ ,h °° S s ' s - 

.ha. overcome such disad».„„ 9 « „„ , na , proviae rt.aT,^ "* ""^ !harin » 

IV. Summary of the Invention 

a first web server (e.g.. by use name Z Z^oTT^TJ'T^ " embodiment ' ■ —r * authenticated a 
service se.ector (e.g. a hyperlink c^^TZ SrJo^T.ZI T PWW " ' P39e to the USer havin 9 a 
se.ector). Upon activation of the -ilSEttTl^i - ^ W the Service indicata < «* the 

encrypted authentication token (e g a c^oWeVfrom th fi J t wlh 7' COnStmcts ' di S ttal| V «8"«. and transmits an 
encoding Is emp.oyed to encry t an Zgn he Z^n^T^eTZ^T^ S6rVerviatbe 
domain. The authentication token comprises an exolm^on Tml th J™ SeCOnd Web sen/ers share a ch- 
eated at the second web server an ^URL decoding I -T^^ "T^*™ ^ iS 6Xamined and a ^e"«- 

K?" T s »r ™ expiration time has not 

user at a computing device S s a ^Zs.'Zr^fJ" 6mbodiment - the method comprises allowing a 
puting device authenticating the user JTv^JZZZ? 1 T™" °' "* MrVW8 Via 3 W6b browser of fhe «>"> 
tion. by the first web server'and ZZZ Zu^ZZ^T.T "Tf^ inC ' Udin9 * tea * 3 USer 
tint web server carries out he f^^a^S^T , T 3 W8b ° Uring the session - 

ond web server, and r.,^ ZIZZ^ Z'^"' 9 ™. USer of a functionality offered via at least a sec- 
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web server by the first web server, and senZ , the au5 TrtltTu 7l\! ^ ^ W6b bTOWSer t0 the sec °" d 
The second web server decrypts he .SI^ STS^ VT "* by the web bro -ser. 

server, checks the pre-definedexpiry of S^S^t^Z^ digital signature of the first web 

.oct a session with the second webserver 

SLa^r^ - -ers. comprising receiving , og , n 

the service selector, constructing an aJZertteZ?^ 'ector receding an rndication that the user selected 

and signing the authentication oken u^JT^^ f ^ enC ^ tinQ 

the user, receiving the authentication tokenl ftfi^„„H . S6rVer ' tfansm,ttin 9 the authentication token to 

and aHowing the user access toT^^Z^S^^^ T aU,he " tiCation toke " *• second server, 
token emprises a cookie and further c^^^^r^ °™ ^ - ^ntication 

Lesstoa^de^ 

tion's web site to have access for exTml^T V authent,cated on a web site, such as a financial institu- 

provision of a va.id name and paLorT' ' ^ Pr ° V ' de '' S ™* ~* W " houl ^ t0 be -authenticated via 

Soda^^^^ 

authentication at an entity's web site seror sT^TcH « °> ■! fl^' 0 " °' W6b S6rVerS that allows 
token by the entity's web site server to TsT^c^Zfl^ZTl ^ °' 3n ^"-^ation 

ice provider's server, for example to recoqnfce Z llr 1 T SUff ' C ' ent information '° enable the serv- 

customer specific information. * " S 8 ^ S *™ e PTOVider user and to provide the user with 

may b. te « med by praclic. or ,h« iZZ, **" " ar > u e°" «*»"m.«o„ of me following, or 
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RG 2 s h how S s a fl n fr mb H diment ? 3 SySt6m aCC ° rding l ° ,he bresent inven «on. 

snow: in RG ' 9ram d6SCribin9 3 PrOC6SS aCC ° rdin9 ,0 ,he V™** Mention carried out in the svstem 

system shown In FIG. 1 < feo *' n !l « P™b.ss .ocorrjing * me presen , cmfea ^ |n ^ 

VI. Detailed Description 

K, 30 in«ud^ **• Mention. A brokerage firm web server 

web site 32) is in communication ^toXTna zl u^^Z "? ^ 3 ° (and the brokera 9 e "™ 

bank web server (BWS) 40 (and .ikewise the bank wah if ? W ^ 4 ° inC ' UdeS 3 bank web site ^ The 
tomer 5 of both the brokerage firm and the bank is sTown ThI™ f ° C ° mmunication "«h the Internet 20. A cus- 
both the brokerage firm web site 32 and the ban web site 42 Th ZZ , ' 8nd PaSSW ° rd to access 

browser such as Mbrosoft .nternet E^^^^J^,^^. PefS ° nal COm P uter 10 ba ™g a web 
as we... The customer 5 uses the customer's C " em) " commu ™ a «°n with the .nternet 20 

30, 40 via the Internet. Herein the taWStE^ S br ° WSer 1 ° l ° com ™™ate with the web server 

customer. |„ addition to '^^ZSS^S^T' mStanC *V° the C ' ient 10 as used b V 

rr4r^G°rh priseprogrammin9to ™ 

the customer's correct user nam '(or^se^ 

authenticated by the brokerage flnn^S^fSS .h br ° kera9e W6b Site 32 ' and >* 

web site 32 presents the customer 1 0^TSl^? 8 C " : ^ bf0kera9e firm web site ^ ^ 

examine the customed brokerage ^ SST^ tT? S " r ? t ^ thS CUSt ° mer 1 0 ma V 

rnnici cir- o ^ L «-«uni information, portfolio, investment information and the likp. 

[0015, 3 shows a graph.ca, depiction o, the system shown in FIG. , . induding the Cme page ,00 from the 
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r ::sr P ; e e b ^ e "rz^^:^;^; * - - — ge firm web site 30 . 

102. The bro kerag e web site offers its customs the a ^ to pTy bi.^ 3 ^ 35 ^ Paymen <- 

K, The^S™ ^ 50 " " - ™ P^enr hype, 

grammed with the knowledge that the bank web set er vE^^T*" "! ** *» M,Ver 30 iS W 

of the bank web sfte 42. Upon detecting the ££££ ?" 1 ° 2 inC,UdeS ,hG URL 

ton token 52. An authentication token comprises an 0bS O rT a ?I; th , 1 9 30 bui,ds an authentica- 

tion of an embodiment o, an authentLton St2f tocon C °° Peratin9 ^ 
server to a secondary (or second) server to allow the secondary sewiostoZZ^T T 3 ( ° r finSt) 

be necessary and required. Once a primary server establishes ^Zl k ptheS ' 9 P™ess that would otherwise 
that receives a va.id authentication token £ the pr Cr^S £2^^ 

™e^^ an authentication token ( or 

data comprises user identification data comprising a cusL Pr 2p„trT 3 (t ° ken CXpiry) 52 The P rofi,e 

the secondary server. In the shown embodlm^fte^^^S^"^ ""'^ ktant " a8 the User t0 
time data comprises data reflecting the time after which .h* 11 ° ° aCC ° UntS 0f ,he ^tomer. Expiration 

the time is in Greenwich Mean Time (GMT, ^nlTZZ^TT ^ " ^ the ^bodiment shown, 
may be set by the primary server at any JelTZeTolTT^ J T * * ^ EXpiratio " tim * 

short time, e.g., three to twenty minutes from the time a wh£ h the S I f l™"* time is a relative| y 

shown, the expiration time is set at fifteen minutes mm ^Tr T at '°° ^ >S Created ' ln the embodiment 
important forthe servers exchanging authentication token is created. Mote that it is 
expiration time is used to create a Jngle-use pe^Se token °' Synchroni2ed cl °<*s. The use of 

25 ST. with profile data of the cus- 

comprise URL strings or other data that may be passed LZ e TJ T r ,0ken - Authentica «™ tokens may also 
customer identffication number for the customer 5 The b*! Z h P *"* °' ^ CUSt ° mer inc,udes a 
(e.g„ a hard disk drive) that has customer ^t^ ^T^^ZT * St( "* 9e SyStem 

of the brokerage firm web server 30. These number* ZZ aaZd u^nl ^ ^ USed by ^tamer's 

30. 40. In the embodiment shown, a customer Tasl^ZZT, Tr P ™T * administrato ^ of the servers 

when the customer requests bi„ payment ^Z^^^^^^^ emb ° di ™nt, 
tification number for the customer 5 This customer Id^mm^n k St ° rage SyStem ' the customer iden- 

build the cookie 52. customer .dentrf.cation number retrieved is used in the profile data used to 
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35 [0019] In another embodiment, various customer identification n .,mh fl 

servers. When the customer requests a service prided a! I TZ« Z , " 8SSOciated with ^lous secondary 
the primary server detects the request ^S^^^l^T^ T ^ '° transferred to a secondary site? 
customer identification number fo'r the ^SSSS^ ^ ^ ^ ^ ^ *» 

tomer will be directed for bill payment services. associated with the secondary site to which the cus- 
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So by ::iti 9 ng a r %z — ™— ™ 5. The se^ 30 

ondary server to handie the request. In toe e^^Z ZTZ™ 9 ^ ' °' ^priate sec- 

made by the customer. In the present e^o^eTZ ^ZLln 'l" T^** ^ " bi " Payment " re ^ uest 
Locator (URL) associated with the "bill payment Z P M X w.h JZT*" det6miihin 9 ,he Unifo "" Resource 
includes the URL associated w,h the i ZnJE£^j£^£^^ «• 1 °0 

^^0^0^^ 

interface (API) library, available from Entrust Tech nologtes^nc ^ Te^s * ™™™9 
key encryption system, in the embodiment *J^J^^^ZT^^^^^ U ^ 
encryption algorithm system, the encrypted cooWe uses nriv»^ T ? P 6 DES (Data Encr VP«^ Standard) 
Secura Hash Algorithm (SHA-1) to create the nZL^^Z^TT ^ (PEM) headere ' a " d -Bnlng uses the 

Fur*.,. ,he signature allow, a sacoarj.^ aa" ar » . 7" ^ se ™» 30 

Tha nig,*, agMure „ applied 8na ^^'^ « »"upliaa ol ma authaaficaB.n «.„. 
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Ln?™ n J embodiment show ". the cookie is created and kept on the browser 10 of the user 5 using a header 

2 ? reSP ° nSe PaQe ' and the header entr * is structured as fo"ows: Set-cookie; name = va.ue- expiate U? 

oreZLt^'T 3 " 61 Pa L h ? ath; S6CUre - The Pa,h ^ COmpr,Ses a s P ecific a " d the dominate iTue 

preferably s a common sub-domain (discussed further be.ow). In an embodiment, the authentication tokenTtnTcookS 

Z2?r IT'" 66 Writte " l ° diSk ° n the CUS,0mer Client 10 '" such a " embodiment, an expire Suet 
not necessary, and the cookie will be deleted by the receiving server immediately after receipt 

fs 00 as 4 fo..ow S An 6XamPle °' 8 Stri " 9 COmPriSin9 C0 ° kie Cons,ruction accordi "9 «° embodiment of the present invention 

10 VERI1EXPDTI1 99905051 32540IICTVCUSTIAFIEXISTIICIDI576001 00056005023 4II 

FCIDI0IITAI2IIANMI001 0000001 IIRTNI099IIANAIMy wife's 
CheckingllABI237600IIANMI0010000002IIRTN009IIANAIMy 

checkingllABI24556. The example is in the following format: Tag1 TagValuel Tag2 TagValue2 Tag3 TagValue3 .... 

" Z^'J^SZ^ ^ th6ir Va,U6S ^ aCC ° rdin9 t0 ion needs, such as 

[0026] Tags in the example shown, their value, and a description is shown in the following table: 
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Tag 


Tag Value 


Description — j 


VER 


1 


Version of cookie system being used (current version is 1) 


EXPDT 


Date / Time 


M^DhS^ date t,me aUthentlcation token ex P'» re S- Format: CCYYM- 


CT 


CUST FC 


Customer Type. CUST= regular customer. FC= Customer Representative Used to 
activate view-only mode. 


AF 


NEW / EXIST 


New or existing customer indicator. 


CID 


Integer 


Customer Identification Number 


FCID 


Alphanumeric 


Identification number for customer service representative. If the user is a regular cus- 
tomer, do not set FCID (i.e., set to 0). 


TA 


Integer 


Total Number of Accounts of customer ~ " " " 


ANM 


Integer 


Account Number — . . _ _ 


RTN 


Integer 


Routing transit Number - maps to prod-type-cd 


ANA 


Alphanumeric 


Account nick name ~ " " ~ 


AB 


Integer 


Account Balance in cents (i.e. $1 0.50=1 050) 
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[0027] In the embodiment shown, the order of tags is not significant, except for ANM ANA AB which are con.iri 
ered a tup.e and are grouped together as shown above. Also, in the embodiment shown the VEF (EXPDT and CT 1" 
required tags. Other tags that may be used in other embodiments include the following AG (agency oT' coroomZ 
name that employs the user). FNAM (first name of user), and LNAM (last name of use" corporate 

L^n AF 189 a " 0WS the bank SerV6r 40 10 determ i"e if an "Activate User" message should be sent to a trans 

act.on processing system (TPS). Preferably, if the brokerage firm web server 30 cannot determine whether a cus Zl'r 
-s new or already enrolled with GTPS. the server 30 sets the AF tag to NEW. In addition the brokeraae Tm weh lZZ 

v ~ r e r ,hat aH accounts are of the " checkin9 " and - - - p-cC"~:™ 

S« all Th ^^ okera 9 e firm server 30 then URL encodes (also called URLEncode) the constructed cookie 58 
U? en^^d fonm^ 9 the :°T e - br ° ker fimi W6b se — v ^ the formatted string discussed above 6 t f a 
comnric t k embod,ment - m e URL encoding encodes the string using the URL escape syntax wnfch 

composes a three character string (%nn) specifying the hexadecimal code for a character This svnSTs used t ^2 

Tr^ZT T be othewise significant when used in a URL The url T^JZ 
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[0030] The brokerage firm web server 30 then sends a redirect command (or redirect page) with the URL encodPrt 

URL r aUt h he, ; tiCati0n t0ten) 3 Set *°° kie ^ t0 ,he CUSt0 ™ c,ie "< 60 The <^Z^S££^ 
URL of the web s.te assoc.ated with "bill payment" 42. The customer client 1 0 receives the redirect command and he 
URL encoded cookie constructed by the brokerage web server 30. he 

hTJ 1 k ^ diem 10 C ° nneCtS With the bank web site 42 ™ tne ,n,ernet 20 and sends the cookie to the 

bank web server 62. In the embodiment shown, the authentication token is transmitted in a Secure Sockets LayTr SSL) 
sess.on. Further, ,n the embodiment shown, on receipt ot the redirect command, the customer client opent I i siSnd 
browser w.ndow requests a downioad of the home page at the URL of the web site 42 (or the page designated in the 
URL) racen.es the page of the web site 42 from the bank web server 40. and displays the page in the window An 
embodiment of such a window 110 and page is shown in FIG. 3. The cookie received by the customer clieT Zr om 
he brokerage firm web server 30 is sent by the customer client 1 0 to the bank web server 40 

KLJ?* bank . Web w SerVer 40 receives the cookie <™ the customer client 1 0. The bank web server 40 decodes 
the encoded s,gned and encrypted string built into the cookie by the brokerage firm web server 30 into a siqned 
encrypted stnng 64. Such decoding emp.oys URL Decoding (or URLDecode) methods in the embodiment shown t 
the embod.ment shown. URL Decoding is emp.oyed to convert the URL encoded string in the cookieTpfc in ASCM for 
exam.nat.on by the bank web server 40. The bank web server 40 and ,he brokerage firm web server S pravtoul 
exchanged public-private key decryption information. previously 
[0033] Once the string is decoded, the bank web server 40 decrypts and verifies the cookie .inHndinr, , ho „i„ h 
encrypted string that is now decoded) 66. In the embodiment ^software ^^^^^ 

ware capable of decrypting and authenticating electronic transactions across applications and sa^ * £e 

bank web server 40 to do so. One example of such software is the Entrusts. 5.0 software package wS, ^ocTated 
applicahon programming interface (API) library, available from Entrust Technologies, Inc., Piano Texas aSS ° C ' ated 
^11 , , k S6rVer 4 °' USin9 the SOftWare me "tioned, determines whether the digital signature associated 
w.th the cook.e verifies 68. If the signature does not verify, the bank web server 40 rejects the attempted s^on and 
£;um?0 S T"™??! 10 t0 3 Web ^ on 'he brokerage firm web server SO^ndicating an error and sign on 
fa.lure 70, resurt.ng ,n a fa.led s.gn-on attempt 72. In another embodiment, if the signature does not verify the bank v^d 
server 40 rejects the s,gn-on and sends a web page indicating an error and sign-on failure to the customer client m„ 
an embodiment. ,f the signature does no. verify, the bank web server 40 also sends a message indSTng such faSu ra 
to the brokerage f.rm web site 30. e.g., an e-mail message. indicating sucn failure 

[0035] If the signature verifies, the bank web server 40 examines the Certificate Authority (CA) name associate 
w*h the cookie 74. The server 40 compares the CA name associated with the cookie (i.e.. the' CA usTd wi'thTcA 
name expected, as recorded in a registry file in the bank web server 40). If the CA name is nouhe one expfcted the" 
bank web server -40 re-directs the customer client 1 0 to an error page on the brokerage firm we server 70 and te sign 
on attempt fails 72, as described above. lne s '9 n 

[0036] If the CA name is the CA name expected, the bank web server 30 next if the sender's name is correct 76 In 

name beinoceimL" ^ ™ 30 *" C ° mm ° n Na ™ < CN > aSSOciated »he cookie^ th 

?H p 7^ T 7. " ame US6d by the br ° kerage ,irm Web server 30 > fe an authorized name. In so deteLininq 
the bank web server 40 compares the CN associated with the cookie with a file containing authorized names Ta data 
reg.stry m the bank web server 40. .f the CN is not the one expected, the bank web server 40 re-directsThe corner 

^7! ^hrc 0 ^ 896 ° n f 6 br °, kera9e fimi ^ SefVer 70 and the Sia "- 0n -"^ fails ™- - deSibed abtvT 
[0037] If the CN is correct, ..e.. .f the CN is an authorized name, the bank web server 40 extracts profile data from 
the cook.e and beg.ns a bill-payment session 78. In the embodiment shown, the server 40 pals the ctear tS date 
associated wrth the cook.e (clear text refer* to the information that is not encrypted) 78. and examines* e^ratSn 
fme data .n the cook.e (not shown). If the expiration time has passed, the bank web server 40 re tracts tie corner 
ckent 10 to an error page on the brokerage firm web server 70 and the sign-on attempt fails 72 a TscTibe Talove 
The clear text data includes profile data (e.g., customer identif nation number). If the expiration th^J^S^^. 
web server 40 begins a bill payment session using the session and profile data 78 by sending7he customer cS tne 
web page 1 ,0 of the bank web site 42 that is showh in FIG. 3. and the sign-on is successful 80 Se^ZiVSSi*; 
reaves the web page 1 00 and proceeds with the bill-payment session with the bank server 40 In an en^bXent the 
authent.cat.on token (cookie) is then discarded or destroyed by the web server 40 emDod.ment, the 

[0038] In an alternative embodiment, the system reflects a service associated with a user's employee One such 
embod.men, ,s shown in FIG. 4. .n the embodiment shown in FIG. 4. the process of this alternative enZ^Zener- 
ally proceeds as that discussed above, with exceptions discussed below. The embodiment shown e7pC a Pnmarv 
server compns.ng a central web server having a central web site (not shown). The central weo s« comple Z 
arte at which the customer client 1 0 may request various services by clicking a hyperlink P 

[ 158 39 160 1 1 ^VeeTsB^O TT^r ^ °" * ^ ™* ** ^ PrOC6SS 15 °" 152 ' 154 ' 1 56 . 

56 58 60 6P 64 RK L 7n 7 7 : 74 ',? nt,nues ,n a manner -like that described above in relation to steps 50, 52, 54 
56. 58. 60. 62. 64. 66. 68, 70. 74 shown FIG. 3. with the central web server serving as the primary server (me brokerage 
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web server served as the primary web server in the embodiment shown in FIG. 2) until the step shown as item 77 
occurs. The primary server includes the following, additional tags in the cookie: AG (agency or corporation name that 
employs the user). FNAM (first name of user), and LNAM (last name of user). The service provider referred to in FIG 
4 comprises the secondary server, and in the embodiment shown comprises the bank web server 40 After the bank 

5 web server 40 determines that the sender's CA is correct, the web server 40 determines whether the customer / user's 
employer has signed up with the service provider associated with the secondary server (the bank web server 40) 77 
The bank web server 40 includes a database containing a list of employers who signed up with the service offered by 
the bank web server 40. The web server 40 compares the agency or corporation name in the AG tag with the list of 
employers. If the name in the AG tag is not on the list, the web server 40 re-directs the customer client 1 0 back to the 

10 central web site for an error URL 70. 

[0040] If the name in the AG tag is on the list, the web server 40 continues the process by extracting profile data 
from the cookie and beginning a bill-payment session 78. After the bank web server 40 extracts profile data from the 
cookie and begins a bill-payment session 78, the server 40 examines a database (not shown) associated with the 
server 40 that includes data reflecting users who have previously signed up for or used the service provided by the 
is server 40. If the user reflected by the cookie exists (i.e., has previously signed up for or used the service provided by 
the server 40), the web server 40 retrieves a default web page previously selected as the user's default page and sends 
the default web page to the customer client 83, and the customer client 10 then may proceed with a bill-pavment ses- 
sion 80. ' 

[0041] If the user reflected by the cookie does not exist (i.e., the database does not reflect that the user has provi- 
so ously signed up for or used the service provided by the server 40), the web server 40 creates a user identification using 
the tag information, including the AG. FNAM, and LNAM tag information, and stores the user identification in a data- 
base. The server 40 then retrieves a pre-designated default web page and transmits the web page to the customer cli- 
ent 83. The pre-designated default web page comprises a pre-designated web page for users associated with the 
agency / corporation indicated in the AG tag. The customer client 1 0 then may proceed with a bill-payment session 80 
[0042] In an embodiment, multiple secondary servers are used in an embodiment of the present invention In still 
other embodiments, multiple primary servers are used. A group of one or more primary and one or more secondary 
servers sharing log-in and other information as described herein may be referred to as a "federation" of servers 
[0043] In the embodiments shown herein, a digital certificate generation software program is used to generate cer- 
tificates. An example of such software is the Entrust Solo Version 4.0 software package, available from Entrust Tech- 
nologies, Inc., Piano, Texas. Preferably, when multiple secondary servers are employed in an embodiment of the 
present invention, the secondary servers will use the same profile (a file comprising information needed by the certifi- 
cate before the server can authenticate). Also, preferably, the CN name in the profile matches the generic host name of 
the secondary server. 

[0044] In embodiments, multiple primary servers are employed. The primary servers may use the same profile on 
all hosts or each host may use a separate profile. Like the secondary servers, certificates are employed in each primary 
server. 
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[0045] In an embodiment, servers sharing information between themselves that are maintained by different organ- 
izations use a shared domain in common in order to ease the sharing of information. In such an embodiment, a sub- 
domain is established or designated as the common sub-domain, the domain attribute of the authentication token (e g 
the shared cookie) is designated as the common sub-domain, and a "Forward IP (Internet Protocol) Pointer" entry is 
added in the DNS name servers of the cooperating organizations. 

[0046] For example, the primary server sets a cookie sub-domain of xxxx.yyyy.com (wherein yyyy.com comprises 
the domain name of the primary server). Using -tail matching/ cookies may be shared with any host whose domain tail 
is "yyyy.com.- When the server searches a cookie list on the user's computer for valid or useable cookies the server 
compares the domain attributes of the cookie with the Internet domain name of the host. If there is a tail match then 
the cookie will go through path matching to see if it should be sent. Tail matching" means that domain attribute is 
matched against the tail of the fully qualified domain name of the host. For example, a domain attribute of -xxxx corn- 
would match host names -yyyy.xxxx.com- as well as -zzzz.yyyy.xxxx.com.- For example, the primary server with which 
the user interacts has a domain name of qqqq.yyyy.com, and the secondary server has a domain name of 
ssss.rrrr.yyyy.com, may share cookies in such an embodiment. In an embodiment, the IP pointer in the domain name 
server associated with the primary server either (1) maps the secondary server domain (ssss.rrrr.yyyy com) to a pre- 
des.gnated IP address associated with the secondary server; or (2) delegate the zone "mr" to a DNS name server 
associated with the secondary server for resolution. 

[0047] As discussed above, certain embodiments of the present invention employ URL Encode and URL Decode 
The following is a code fragment written in Microsoft C++ 6.0 showing an example of the implementation of URL 
Encode by a server: 
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// 

s // URLEncode converts some characters to %xx format for sending 

// in a URL or writing to a cookie 

// 

w void URLEncode (BYTE* szDecoded, BYTE* szEncoded) 

{ 

BYTE* pszInPtr = szDecoded; 
BYTE* pszOutPtr = szEncoded; 
BYTE inch; 
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while ((inch = *pszInPtr++) != '\0') 
{ 

if( ' (inch < 32) || (inch > 127) || 

(inch = = '=') || (inch = ='?') || 

(inch = = '&') || (inch = = '+•) || 

(inch = = '%') || (inch = ='-') || 

(inch = = ':') || (incn = = V) n 
(inch = =',')) 

{ 

*pszOutPtrH- = '%'; 

sprintf((char*)pszOutPtr, "%02x", inch); 
pszOutPtr += 2; 

} 

else 

*pszOutPtr++ = inch; 

} 

*pszOutPtr++ = l \0\;; 

} 

[004BJ The following code fragment shows the implementation of URL-Decode by as server: 
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// 

// URLDecode converts characters in the %xx format back to their 

values 

// 

void URLDecode (BYTE* szEncoded, BYTE* szDecoded) 
{ 

BYTE* pszInPtr = szEncoded; 
BYTE* pszOutPtr = szDecoded; 
int inch; 

while ((inch = *psz!ntPtr+-+) != '\0') 
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{ 

5 if(inch = '%') 

*pszOutPtr++ = (unHex(pszInPtn-+) « 4) + 
unHex( *pszInPtr++); 

10 else 

*pszOutPtr-t-+ = inch; 

} 

*pszOutPtrf+ = 4 \0'; 

} 

int unHex (BYTE hexChar) 
{ 

if ((hexChar »= '0') && (hexChar <= '9')) 
25 return hexChar - '0' ; 

if ((hexChar >= 'a') && (hexChar <= «f )) 

return hexChar - 'a' + 10; 
if ((hexChar >= 'A') && (hexChar <= 'F'» 

return hexChar - 'A' + 10; 
return 0; 

} 
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[0049] Those of ordinary skill in the art will recognize that there are a variety of code fragments useful in carrvinn 
40 out such steps. Further, a variety of programming languages may be used fragments useful ,n carry.ng 
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Claims 

1 . A method of single sign-on user access to multiple web servers, comprising: 

so authenticating a user at a first web server; 

transmitting an encrypted authentication token from the first web server to a second web server, wherein the 
atrthenteat.on token composes an expiration time and is digitally signed by the first web server- 
authenticating the authentication token at the second web server; and 
allowing the user to conduct a session at the second web server. 

2. The method of claim 1 wherein the first web server and the second web server share a sub-domain. 

3. The method of claim 2 further comprising examining the expiration time of the authentication token at the second 
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web server and allowing the user to conduct a session at the second web server only if the expiration time has not 

passed. 

4. The method of claim 3 wherein the authentication token comprises a cookie. 

5. The method of claim 4 wherein transmitting the encrypted authentication token from the first web server to the sec 
ond web server comprises transmitting the encrypted authentication token from the first web server to the user and 
then from the user to the second web server. 

6 ' password 0 * °' C ' aim 5 Wh6rein aUthenticating the user at the ,irst web server comprises receiving a user name and 

7. The method of claim 6 wherein transmitting the encrypted authentication token from the first web server to a sec- 
ond web server comprises transmitting the authentication token from the first web server to a computer of the user- 
and transm.tting the authentication token from the computer of the user to the second web server. 

8. The method of claim 7 wherein the first web server and the second web server comprise a federation of web serv- 

6f"S. -«- — ^(t.. 

9. The method of claim 8 wherein authenticating the authentication token at the second web server comprises exam- 
ining the cookie. 

10. The method of claim 9 further comprising URL encoding the authentication token. 

11. The method of claim 10 further comprising URL decoding the authentication token at the second web server. 

12. The method of claim 1 1 further comprising providing a web page to the user having a service selector. 

13. The method of claim 12 wherein the service selector comprises a hyperlink. 

14. The method of claim 13 wherein the hyperlink comprises a URL for the second web server 

15. A method for single sign-on user access to a federation of web servers, comprising: 

allowing a user at a computing device to access a first web server in the federation of web servers via a web 
browser of the computing device; 

authenticating the user with user-provided authentication information, including at least a user identification by 
the first web server; ' y 

prompting the user for selection of a functionality offered via at least a second web server- 
receiving a selection by the user of the functionality offered via the second web server- 
creating an authentication token for the user including at least the user identification and with a pre-defined 
token expiry by the first web server; H 
digitally signing the authentication token by the first web server; 

qualffying the domain attribute of the authentication token with the shared sub-domain name by the first web 

sending the digitally signed authentication token to the web browser of the computing device by the first web 

redirecting the web browser to the second web server by the first web server; 
sending the authentication token to the second web server by the web browser; 
decrypting the authentication token by the second web server; 

checking the pre-defined expiry of the authentication token by 'the second web server- and 

allowing the user to conduct a session with the second web server if within the pre-defined token expiry. 

16. The method of claim 15 further comprising allowing the user to conduct a session with the first web server. 

17. The method of claim 16 wherein the second web server shares a sub-domain with the first web server. 

18. The method of claim 1 7 wherein digitally signing the authentication token by the first web server comprising digitally 
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signing the authentication token using public key encryption. 

19. The method of claim 18 further comprising confirming a match with the digital signature. 

20. A method of single sign-on for multiple web servers, comprising: 

receiving log-in data from a user in a first server; 
providing the user with a service selector; 

receiving an indication that the user selected the service selector; 
constructing an authentication token comprising profile data associated with the user; 
encrypting and signing the authentication token; 
redirecting the user to a second server; 
transmitting the authentication token to the user; 
receiving the authentication token in the second server; 
15 verifying the authentication token in the second server; and 

allowing the user access to a service provided by the second server. 

21. The method of claim 20 wherein the authentication token further comprises expiration time data. 
20 22. The method of claim 21 wherein the authentication token comprises a cookie. 

23. The method of claim 22 wherein the log-in data comprises a user name and password. 

24. The method of claim 23 wherein the service selector comprises a hyperlink. 

25. A system for single sign-on user access to multiple web servers, comprising: 



25 



a means for authenticating a user at a first web server; 

a means for transmitting an encrypted authentication token from the first web server to a second web server 
30 wherein the authentication token comprises an expiration time and is digitally signed by the first web server- ' 

a means for authenticating the authentication token at the second web server; and 
a means for allowing the user to conduct a session at the second web server.' 
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26. The system of claim 25 wherein the first web server and the second web server share a sub-domain. 

27. The system of claim 26 further comprising a means for examining the expiration time of the authentication token at 
the second web server. 

28. The system of claim 27 wherein the authentication token comprises a cookie. 

29. The system of claim 28 wherein the means for transmitting the encrypted authentication token from the first web 
server to the second web server comprises means for transmitting the encrypted authentication token from the first 
web server to the user, and then from the user to the second web server 

45 30. The system of claim 29 wherein the means for authenticating the user at the first web server comprises means for 
receiving a user name and password. 

31. The system of claim 30 wherein the means for transmitting the encrypted authentication token from the first web 

server to a second web server comprises means for transmitting the authentication token from the first web server 

so to a computer of the user and means for transmitting the authentication token from the computer of the user to the 

second web server. 

32. The system of claim 31 wherein the first web server and the second web server comprise a federation of web serv- 
ers. 

55 

33. The system of claim 32 wherein the means for authenticating the authentication token at the second web server 
comprises means for examining the cookie. 



12 



DOC1D: <EP. 



1089516A2_I_> 



EP 1 089 516 A2 



34. The system of Cairn 33 further comprising a means for URL encoding the authentication token. 

35. The system of Cairn 34 further comprising a means for URL decoding the authentication token a, the second web 

36. The system of Cairn 35 further comprising a means for providing a web page to the user having a service se.ector. 

37. The system of claim 36 wherein the service selector comprises a hyperlink. 

' 38. The system of claim 37 wherein the hyperlink comprises a URL for the second web server. 
39. A system for single sign-on user access to a federation of web seivers, comprising: 

viaTwlt^ 

with user - provided authemication - — - 

a means for digitally signing the authentication token by the firs, web server 

theTr;; ::zr the domain M ° f the t 0 k en Me shared sub . domain name by 
their;:; i:t° ,he di9i,a,iy si9ned authentica,ion token «° ^ «-» *»™ - ». ****** ^ by 

a means for redirecting the web browser to the second web server by the first web server 

40. The system of Cairn 39 further comprising a means for aHowing the user to conduct a session with the first web 

41 . The system of Cairn 40 wherein the second web server shares a sub-domain with the first web server 

43. The system of claim 42 further comprising a means for confirming a match with the digital signature. 

44. A system of single sign-on for multiple web servers, comprising: 

a means for receiving log-in data from a user in a first server 
a means for providing the user with a service selector 

a means for receiving an indication that the user selected the service selector 

a means for constructing an authentication token comprising profile data associated with th* „ M 

a means for encrypting and signing the authentication token ass °<=.ated wrth the user; 

a means for redirecting the user to a second server; 

a means for transmitting the authentication token to the user 

a means for receiving the authentication token in the second server 

a means for verifying the authentication token in the second server- and 

a means for allowing the user access to a service provided by the second server. 

45. The system of Cairn 44 wherein the authentication token further comprises expiration time data. 
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46. The system of claim 45 wherein the 

47. The system of claim 46 wherein the 
s 48. The system of claim 47 wherein the 
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authentication token comprises a cookie. 

log-in data comprises a user name and password. 

service selector comprises a hyperlink. 
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